Preface #

This post is part of a series in which I explain my Arch Linux installation. Originally, I plan to structure this blog post series into two episodes:

• Episode 1: planning
• Episode 2: installation procedure

However, because I like to play around, I expect to iterate the process and have more than 1 Arch installs. For each Arch install I plan to document the process so this series may be extended to have more episodes.

My goal of installing Arch Linux #

Before doing the Arch installation, it is important to set up the goal. Is it to learn about Linux? Is it to build a daily driver desktop? Is it to have a secondary OS for trial purpose? Having a clear image of how we want to use the Arch will define the sub-component we need to install.

For me, the main purpose doing Arch installation is to learn more about Linux operating system. Unlike other Linux distributions that provide a configuration preset at initial installation (e.g. install text editor, install Libre office, install GUI, etc.), Arch Linux is a minimal Linux distribution where the user is expected to do most of the tasks by him/herself (DIY). Just right after installing Arch Linux from the installer, the vanilla Arch Linux has no GUI and we only interact via command line to build the system. As a user, we have a freedom to pick any technology/implementation to make the machine work for us individually, e.g. choosing the boot loader, file system, desktop environment, etc. This situation would force us to understand about the underlying technology, which is a good way to learn more about Linux operation system.

I am not planning to use the new Arch installation as my daily driver. At the time of this writing, I installed the Arch Linux in my homelab machine. Even though it is not my daily driver, I built the Arch Linux while imagining it to be used as desktop. To be honest I am considering using Arch Linux as my daily driver in the future.

My installation approach #

To align the Arch installation activity with my goal, for now here is my approach:

• Do all of the installation process manually, i.e. not using archinstall, which is a helper library available in live installation medium (USB) to automate the Arch Linux installation. Doing the process manually allow me to have full control over what component to install. Thanks to the hands-on activity, I can maximize the learning experience as well.

• Install Arch Linux in real hardware. There are things that we can experience only by doing the installation on real hardware, instead of virtual machine (VM). There are some variances from hardware that adds complexity to the installation process, for example we need to deal with specific firmware/driver. In this case, complexity to certain degree is a good thing because troubleshooting this kind of issues provides a good learning experience. For my first installation attempt, I am going to use an old Asus tablet PC bought in 2016/2017 ASUS T102H.

• Do the installation iteratively and don’t forget to keep it simple. By making the Arch installation in iterations, there is no need to make my first install to be perfect. Sometimes simpler method/system is easier to learn from. For this reason, in my first iteration I would avoid putting a lot of effort on the aesthetic part, i.e. it should be basic and functional. A fancier installation can be done in the next iterations.

• Always refer to the Arch Linux Wiki. The Arch Linux Wiki is well written and contains a lot of knowledge. It seems that the community puts a lot of effort in maintaining the Wiki, making it a valuable resource to refer and learn from.

Concepts I learned during this process #

One of the most challenging part when building the Arch Linux machine is understanding every components of this distro. What makes this challenge even harder is, each component often time has multiple selections of technology/tool that we can choose from. In short, there are a lot of concepts that we need to understand so we can build an optimized machine for our needs.

Before diving into the procedure to install Arch Linux, which I will cover in the future blog post (episode 2), I want to share at high level some concepts that I learned and documented in my note.

Installation live media (USB) #

Installation live media is a bootable medium (can be USB or DVD) that contains a full operating system. We can run the operating system directly from the medium. To be specific, when booting from the live medium, the Linux OS file system will be loaded from USB medium to the computer RAM, and the CPU runs the OS from RAM, while reading some files from the USB medium if necessary.

Why does installation live media exist? What kind of use case does it serve?

• To try the OS. Some Linux distributions provides a full-fledged desktop environments in the live medium. When we boot from it, we can try out some features.
• As a system rescue. Because the live media system can load independently from the OS in the hard drive, we can rescue the main OS in case we cannot even enter the main system.

In short, the Arch installation live medium contains utilities that we can use to install Arch Linux into our hardware.

Linux boot process #

If I were asked to explain the Linux boot process, I would elaborate it as 5 main steps.

• Step 1: BIOS/UEFI. BIOS (basic input/output system) in older system, or UEFI (unified extensible firmware interface) in newer system, is a piece of firmware installed in our computer’s motherboard chip. Note: in most cases we can only choose one between BIOS and UEFI. The main goal of BIOS/UEFI is to perform power-on self-test (POST). In easy words, POST is a test executed by our system firmware to make sure essential components like CPU, RAM, or graphic cards are working properly. Another mission of BIOS/UEFI is to identify Bootable device, usually it is a storage device (can be hard disk or USB stick, just like the USB installation media), where the a small software component called boot loader is stored.
• Step 2: boot loader. Boot loader lives in a small partition inside the Bootable device. The main function of boot loader is to load Linux Kernel into memory. Another function of boot loader is to present a list of kernel or operating systems where we can boot from (e.g. we have dual operating system installed).
• Step 3: Kernel. Kernel is the core of operating system and is responsible for managing hardware, memory, and processes. In the boot process, Kernel’s main task is to initialize device and drivers, and also mounting the root file system, which contains other components of operating system. The problem is, the Kernel might not have the necessary driver to access the root file system from the storage device (e.g. Need specific SATA controller, RAID array, or encrypted disk). To get the driver, the Kernel can compile the driver on startup, however this process is slow. So Kernel utilizes a special package containing required drivers to access the storage device. This special package is called initramfs.
• Step 4: initramfs. Initramfs is a small, temporary, in-memory file system that contains compressed tools/drivers that will be used by the Kernel to access storage device and mount the root file system.
• Step 5: init process. Once the root file is mounted, the Kernel will start the first process (it has Process ID PID=1) called init process. All other processes in Linux user space is called by this init process; in other words, init process is the parent of all other processes. The main goal of this step is to initialize the system a up to a state in which the user can start using the system. The init system launches services or daemons related to logging, networking, or user login. This is the final stage of the boot process. When this stage finishes, the system is ready to use.

Service and process. #

Process is any program or application that is running in the system. A process can be running in foreground (visible to user), or can be in background (user doesn’t interact with it directly). A process is identified with a Process ID (PID). Use ps or pstree to show active processes.

A service is a special kind of process that is running in background, usually started automatically on startup. We can use systemctl utility to manage a service (e.g. start, stop, or query status).

Disk partitioning, file system, disk encryption #

Disk partitioning = to create a logical separation, called partition, in the disk so we can format that partition to use a particular kind of file system. When we are dual booting OS, most of the time we may want to create separate partition for each OS, although on a certain case we may want to create a partition that is shared and can be accessed from both OSes.

File system = a system that defines how data is stored, retrieved, or managed on a storage medium. Different operating system may use different file system, e.g NTFS in Windows, ext4 or btrfs in Linux, zfs in FreeBSD or Linux. Some file systems may be widely compatible yet lacks of advanced features, or some may have a capability to take snapshot. Choosing a file system really depends on our use case, and the best file system is the one that match with our needs.

Disk formatting = an activity of initializing a disk partition with a file system of our choice.

Disk encryption = an activity of securing a disk with cryptography. Without the cryptographic key, the file system cannot be accessed (it is just a garbled binary and character). Usually we want to perform the encryption when installing the operating system (during the disk partitioning and formatting), when we haven’t written any sensitive data to the disk yet.

More info about the boot loader #

Previously I mentioned that boot loader lives in a small partition of the storage device. If we read older documentation, we may come across a word “MBR” (Master Boot Record). MBR is a special area where the boot loader is located when we use the BIOS technology. Lately, more modern hardware uses UEFI. In the UEFI world, the boot loader lives in a dedicated partition called EFI System Partition (ESP). The EFI partition should be formatted using the FAT32 file system and usually not encrypted.

There are various boot loader systems we can choose. Each of them have different characteristics. Again, the best boot loader is the one that match our needs. Here are some overview of the boot loaders.

• GRUB2: Legacy setups yet supports various features like dual/multi-boot, advanced chainloading, or system recovery.
• Systemd-bootloader: Modern, single-OS Linux (esp. systemd-based distros), and has minimal setups.
• Limine: Lightweight, modern, has GUI support. Still early, not suitable for production

fstab #

fstab stands for File System Table. It is a configuration file that tells which file system Linux Kernel should automatically mount at boot time. The fstab file is located at /etc/fstab. The fstab configuration file contains information like device partition, file system type, mount point, and other options.

chroot #

Chroot is a program that can change the “apparent root” path viewed by a process and its children.

Chroot works by creating an isolation at a specific directory, and initiating a new shell inside that directory. The process and its sub-processes will see this directory as the root directory. When calling the chroot, below will happen:

1. The root for process chroot and it’s child processes changes from /mnt to /.
2. Chroot calls a new shell (e.g. bash) inside that new root.

When we boot a Linux from a live installation/rescue media, changing the apparent root directory is very useful because a lot of applications would expect to find certain components or configuration files at /.

Consider a situation where our system image is broken and we are unable to boot to the system. To rescue it, we can boot from a live USB, mount the broken system at /mnt, and reinstall Linux image system. See operation below. The chroot here is essential because by default package managers (e.g. apt, dnf, pacman) always use directories like /etc/apt/, /var/lib/dpkg/, /usr/bin/ based on the root /, not /mnt/etc/apt/ etc. If we run the apt-get command outside chroot, the package manager would reinstall the linux-image for the live USB system instead of the broken system.

  # Mount the broken system at /mnt
  mount /dev/sda1 /mnt
  
  # Enter chroot
  chroot /mnt
  
  # Repair the system
  apt-get update && apt-get install linux-image

Localization (locale, keyboard layout, font) #

System Locale #

System Locale defines the display language and regional settings (how to format currency, date, or time) of our system. In low level configuration, setting up locale consists of three steps:

1. First step, prepare the blueprint at /etc/locale.gen. This file is a template that we will use to generate binaries locale file. This file contains a list of languages that our system can use. By default all lines in that file are commented out. We need to uncomment languages we may want to use. For example, because I want to use English primarily and may use Japanese optionally, I should uncomment the line with “en_US.UTF-8” and “ja_JP.UTF-8”.

2. Second step, build the locale binaries with locale-gen command. This command reads the blueprint we specified at /etc/locale.gen, and for each uncommented line it builds locale data in binary format. These binaries contains information such as language, currency, date and time format. In Arch linux, these binaries are stored at /usr/lib/locale/locale-archive.

3. Third step, select the locale binaries we want to use by specifying it in configuration file at /etc/locale.conf. Inside the configuration file, we should choose the locale we want to use by setting variable LANG like LANG=en_US.UTF-8.

Keyboard layout #

For US keyboard we can simply use the default, because I’m using a keyboard with Japanese layout, there are additional steps needed. The keyboard layout configuration is done in 3 stage.

• Stage 1: define keyboard layout for the installation process. We can execute loadkeys jp106 to set japanese keyboard layout at current shell session. If the computer is rebooted, the configuration will disappear.
• Stage 2: make the keyboard layout persistent even after reboot. To do so, we need to put KEYMAP=jp106 in a configuration file at /etc/vconsole.conf file.
• Stage 3: define the keyboard layout to use in graphical session of X11 or Wayland. This is a post installation process. If we use KDE or Gnome, there is usually “Keyboard” or “Region and Language” section in the system settings window. For Hyprland, we should define the layout in Hyprland configuration file which is typically located at ~/.config/hypr/hyprland.conf. Below is the example of Hyprland config to use Japanese layout as default and us layout as fallback. We can press Alt+Shift keys to toggle between those layouts.

  input {
    # Set the default keyboard layout and a second one.
    kb_layout = jp,us
  
    # Set the key combination to switch between the layouts.
    kb_options = grp:alt_shift_toggle
  }
  

Font and input method #

In addition to the usual alphabet, I also need to read or write Japanese characters. For this reason, I should install font which support Asian characters, otherwise the Japanese characters will be shown as squares or garbled text when an application tries to display them. noto-fonts-cjk is one example of font that support Japanese Hiragana, Katakana, or kanji.

Font handles the aspect of character display. When we want to write Japanese characters, we should configure Input Method Framework (IMF) and Input Method Editor (IME). The relation between IMF and IME is like Display Server (Wayland/X11) to Desktop Environment (Gnome, KDE). IMF is the lower level platform that provides a framework so that input methods can communicate between applications. On the other hand, IME is an application closer to the user side that can help us convert Latin characters into non-Latin characters (e.g. Japanese). Being closer to the user side, IME often features the graphical user interface that previews word suggestions, conversion algorithm, or dictionaries.

This Arch Linux wiki page shows common IMF and IME combination we can choose. For IMF, IBus and Fcitx5 are the most popular, while for IME, Mozc is the most recommended app.

GUI system #

The graphical user interface In Linux comprises of several layers as pictured below (diagram’s taken from this Baeldung Linux article). The layer closest to the Kernel is display server, and the layer closest to the user is the Desktop Environment.

+---------------------------------------+
|          Desktop Environment          |
+-----------------------------+---------+
         ^                    ^         ^
         v                    v         |
+--------+--------+  +--------+-------+ |
| Display Manager |<>| Window Manager | |
+-----------------+  +----------------+ |
                  ^  ^                  |
                  v  v                  v
+---------------------------------------+
|                                       |
|            Display Server             |
|                                       |
+---------------------------------------+
                    ^
                    v
+---------------------------------------+
|                Kernel                 |
+---------------------------------------+

The discussion about each component/layer can be very lengthy and deep. I am only covering brief explanation of each of them.

• Display server: a middleware between kernel and upper layer components. In easy words, it is responsible to render graphics on our computer screen. Example: X11, Wayland
• Display manager (DM): A utility that runs after PC boot, presenting user with login screen. After the user could successfully login, the DM will then present a full fledge GUI (transfer to WM/DE session). Example: LY, SDDM (for KDE), GDM (Gnome), greetd.
• Window Manager: a graphical software component that handle windows in a desktop session. Some window managers have the capability to tile windows automatically. Example: Hyprland, Sway, i3.
• Desktop Environment: a set of graphical software components that make up a desktop GUI. Some examples of the component: window manager, task bar, widget, file Explorer. Example: Gnome, KDE, xfce, Cosmic.

In Linux, the most popular Desktop Environments like Gnome or KDE Plasma include Window Manager already. Although, we can use also have Window Manager only in our system without using Desktop Environment. In short, using Desktop Environment is optional, although it is very common.

My Arch Linux stack #

To close this post, I would like to list the technology stack that builds my first iteration of Arch Linux.

• Disk partition. I created 3 primary partitions on my disk.
  • /efi partition: this is the EFI System Partition (ESP for short), where the boot loader application/file is stored. Initramfs and kernel file are stored here.
  • /boot partition: this is an optional partition for Extended Boot Loader Partition (XBOOTLDR partition for short) . In the initial installation, this partition holds no important files, however in the future, additional boot entries (beside the Arch Linux boot entry) will be stored here, e.g. additional boot loader specification entries (.conf file) for dual boot or snapshot, or Unified Kernel Images (UKI)
  • /root partition: where all of my system and user space data will be stored.
  • Swap partition: this is a special partition not to store data, instead it acts as an extension of RAM. When the system run out of memory, the operating system can put more temporary data in the disk. This comes at a cost of more latency (reading or writing data to disk is much slower than memory).
• File system. for this first iteration, I use the simple ext4 file system. It is not feature-heavy as btrfs or zfs, however the ext4 is one of the oldest and stable file systems a lot of Linux distros provides ext4 as the default file system.
• Disk encryption. I used the LUKS to encrypt the whole root partitions.
• Boot loader. I use systemd-boot loader as the Boot Loader due to its simplicity.
• DE or WM. Instead a full DE experience, I try Hyprland as the WM. Usually I use Gnome in my daily driver machine, for current Arch installation I use Hyprland for two reasons. One is simply curiosity. Two, because I want to learn more lower level technologies like screen locking and Login Manager.
• Localization. This Arch Linux system should display language in English while support reading and writing Japanese characters.

Phew, that’s all. Beyond what I expected, turned out this post is quite long. Anyway, in the next post I will cover the step-by-step installation procedure. Cheers!